Many approaches to handling privacy preferences during personal data exchanges have been proposed in the past. These approaches can generally be divided into several product and technology areas: personal e-wallet/data vault products, enterprise specific e-wallet/data vault products, personal privacy enforcing agents, enterprise policy development, enterprise policy enforcing private data management, and enterprise privacy-enhancing data manipulation. The function of each of these is described briefly in the subsequent sections.
Various Personal e-Wallet and Data Vault products and services provide the ability to store, and sometimes share, personal information. Often, tools are provided, usually as a browser plug-in, to allow users to drag and drop from their stored data onto web forms while browsing. In some cases the web site's privacy policy is compared to the consumer's policy preferences and warnings are issued when there is a mismatch. Privacy policies are often based on the Platform for Privacy Preferences or P3P standard. Examples of such products include Microsoft's Internet Explorer and Passport service, Novell's digitalMe, Lumeria's SuperProfile and ZeroKnowledge's Freedom. Microsoft's Hailstorm service is an extension to its Passport service that provides data subject's a repository to store their personal data, and allows the data subject to grant permission to third party services and applications to access that data. The data subject has to give explicit access to third parties to access the data, and limited amount of privacy control is provided in that the data subject can specify who can access the data, for what purpose and revoke access or give access for a limited period of time.
Current Personal Policy Enforcing products are designed to support a user's privacy policy preferences. A few of the e-wallet/data vault products provide some of this functionality, but the products listed here focus on allowing a complex privacy policy to be represented and checked against either a web site's privacy policy or a data requester's privacy policy. These products use a P3P Preference Exchange Language or APPEL as a language to express what P3P policies are acceptable. Agents retrieve the P3P policies associated with a web site and compare them to the APPEL rules. Mismatches result in warnings to the user. The user then takes whatever action they deem appropriate, such as not filling out the web site form. Examples of these agents are the AT&T Privacy Minder and the IBM Privacy Assistant.
Enterprise Policy development tools help an enterprise develop their privacy policy and publish it on their web sites. These tools generally help in identifying personal information in databases and web pages, and help in creating a policy statement. Examples of such tools include the PentaSafe VigiEntPolicy Center, the IBM P3P policy editor, and Idcide Privacy Wall Site Analyzer. Policies are expressed as free form text and/or P3P XML documents.
Enterprise Policy Enforcing Private Data Management products are designed for enterprises to control or monitor access to personal data stored within the enterprise, according to the enterprise's privacy policies. Some of the products focus on support for privacy regulations, some provide both the data repositories and the policy enforcement, while some provide only policy enforcement. Some of the products are out-sourced services while others are technology used to implement in-house solutions. These products are generally access control systems enhanced to allow more permissions specifically for different usages that are covered by the enterprise privacy policies. Permissions are associated with different authenticated users or lists of users that request access to data. Examples of such products include Privaseek Persona p-CRM, PrivacyRight TrustFilter Privacy and Permission Management for the Enterprise, Tivoli SecureWay Privacy Manager, and Idcide Privacy Wall Site Monitor.
Standards have also been developed that promote the exchange of data over the internet as well as through non-internet messaging systems. The Customer Profile Exchange Specification or CPExchange is a standard that defines how a P3P policy can be associated with personal data in an XML message. This policy applies to the data being provided by one party to another, and provides a way for an enterprise to include the applicable privacy policy with personal data exchanged between applications or between organizations.
Enterprise Privacy-enhancing Data Manipulation tools and technologies are used to eliminate privacy issues by transforming data so it is no longer personally identifiable, or to operate on data and produce results that are not personally identifiable. Data mining for trend analysis or targeted marketing can often benefit from these products. These products may be offered as out-sourced services or technology for in-house solutions. Examples are Privacy Infrastructure Inc. AsPrin, IBM Intelligent Miner Family, and ETI*Extract. All of these except the first one are not privacy specific, but are general tools for data analysis and transformation.
However, the above-mentioned examples have several limitations which are addressed by the current invention. These limitations are discussed in detail in the following paragraphs.
One major limitation is that current products assume that a data subject owns all personal data and/or all this data is available in one central repository or enterprise. However, a data subject's personal data is distributed across many enterprises and repositories, and it is not practical to expect all this data to be collected in one central repository, or to be owned by one enterprise or even the data subject. Each enterprise owns some of the personal data they generate about a data subject, such as financial information in a bank, or health information in a hospital. Thus, a data subject's financial data may be held/owned by several enterprises such as his bank, credit card providers and broker, while his employment data is held by his employer and his health information is held by his doctors and health insurance providers. At the same time, the data subject has various other personal data, such as current phone numbers, addresses, clothing preferences, and a wide range of other preferences. None of the current products deal with allowing a data subject to express privacy preferences for controlling access to their personal data that is distributed across multiple enterprises and repositories. While enterprises often offer data subjects an “opt-out” policy by which the data subject can explicitly choose to allow or disallow the enterprise from sharing his data, this is an extremely limiting kind of privacy control since it imposes the policy of the enterprise on the data subject, with little or no capability to express policies specific to each data subject (other than the opt-out/opt-in option to some portion of the enterprise's policy). However, data subjects want complete freedom to specify their own privacy preferences (and not the data owner's or data holder's) on how their personal data is handled, regardless of where that data is stored or who owns that data.
Moreover, the current products that do store a data subject's preferences do so in a limited way, often based on P3P privacy declarations. These are aimed at use in a situation made clear to the data subject by the context of the request. However, a data subject should be able to express complex privacy preferences that include who can access data, what set of data or type of data they can access, for what purpose the access is granted, how long the data can be retained, who the data can be shared with and for what purposes, and whether the data must subsequently be accessible to the data subject. For example, current systems may allow specification of a policy to be associated with the “current purpose”, but there is no way to apriori state a policy for different business transactions like “placing an order”, “requesting information”, “applying for a loan”, etc. for the prescribed purposes. Moreover, current systems will apply the same policy to all data exchanges with a given data requester. However, data subjects often need much more flexibility than is allowed by these current systems. For example, a data subject may choose to allow access to different sets of data, with different policies on usage and sharing, for different requests made by the same data requester, based on the context of the request.
Another feature which is missing in current products is the capability to enforce a data subject's policy even when the data subject is not directly involved. This is necessary if a data subject's privacy policy is to be followed in all business processing. Most of the current personal privacy enforcement products only assist the data subject in filling in a form on a web page with stored data, or in comparing the data subject's privacy preferences with a web page privacy policy and providing warnings to the data subject. This requires the data subject to be online and actively involved in providing the data that is being requested. Others always require a data subject to give explicit approval once to a requester for accessing certain data owned by the data-subject, with subsequent requests being, possibly, handled automatically. However, a data subject may want to setup privacy preference policies which can allow fully automatic release of data, even without knowing about the requester or the request itself. Moreover, one would like to do so even for data that is held/owned by third parties. For example, a data subject may decide to allow access to non-identifying employment data such as work experience, salary range, etc., to anyone who requests such data as long as the privacy policy governing use, retention etc., match those of the data subject. That would enable any interested party to access such data about the data subject automatically via an automatic privacy policy matching process and send the data subject job listings in which the data subject may have interest. Similarly, a data subject may allow access to certain, non-identifiable financial data such as employment status and salary range, thus enabling interested financial institutions to automatically access such data and send solicitations for credit cards/loan requests to the data subjects. Current products lack this feature as well.
Yet another limitation of current products is the inability for data subjects to be able to easily express complex policies on a large set of personal data, in a way that is applicable regardless of the specific representation and data model used by enterprises that store this data. This is important since, as point out above, a data subject's data will be distributed across multiple enterprises and repositories. One way to facilitate this is by supporting an abstract data model, supporting a data type hierarchy, and by grouping data into levels within multiple views. Policies can then be applied at different granularities, to either views or levels within views, with the views themselves described by using both data types and data instances, such as, for example, all phone numbers or just the data subject's cell phone number. Current products do not have this kind of flexibility.
These limitations, along with public concern regarding privacy of personal data, make it highly desirable for systems and methods for enforcing privacy preferences on personal data exchanges across networks.